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Abstract 

The Power and Attitude Control Expert System 
(PACES) is an object oriented and rule based 
expert system which provides spacecraft 
engineers with assistance in isolating and 
correcting problems within the Power and 
Attitude Control Subsystems of the Tracking 
and Data Relay Satellites (TDRS). 

PACES is designed to act in a consultant role. 
It will not interface to telemetry data, thus 
preserving full operator control over 
spacecraft operations. The spacecraft 
engineer will input requested information. 
This information will include telemetry data, 
action being performed, problem 
characteristics, spectral characteristics, and 
judgments of spacecraft functioning. 

Questions are answered either by clicking on 
appropriate responses (for text), or entering 
numeric values. A context sensitive help 
facility allows access to additional information 
when the user has difficulty understanding a 
question or deciding on an answer. 

The major functionality of PACES is to act as a 
knowledge rich system which includes block 
diagrams, text, and graphics, linked using 
hypermedia techniques. This allows easy 
movement among pieces of the knowledge. 
Considerable documentation of the spacecraft 


Power and Attitude Control Subsystems is 
embedded within PACES. 

PACES is being designed and will be delivered 
on a Macintosh II computer using NEXPERT 
OBJECT from Neuron Data as the expert 
system shell. The graphics oriented user 
interface to NEXPERT is constructed with AI 
Vision, a graphics interface tool also from 
Neuron Data. 

The development phase of TDRSS expert 
system technology is intended to provide 
NASA (Code 405) the necessary expertise and 
capability to define requirements, evaluate 
proposals and monitor the development 
progress of a highly competent expert system 
for NASA's Tracking and Data Relay Satellite 
Program. 

Introduction 

The Power and Attitude Control Expert System 
(PACES) for the Tracking and Data Relay 
Satellites (TDRS) is intended to assist 
spacecraft engineers in diagnosing anomalies 
both on-orbit, and during integration and 
testing (I&T) of the spacecraft. It is also to be a 
“knowledge rich” system or information 
repository, providing engineering 
explanations of how TDRS Power and Attitude 
Control Subsystems (ACS) function. 
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Goals 

The major goal of building TDRS PACES is to 
provide NASA Code 405 personnel with the 
expertise in actually building a fieldable 
expert system. This first-hand experience will 
allow NASA personnel to better judge the 
expert system components of proposals, and to 
be more knowledgeable in monitoring and 
managing expert system projects. 

Achieving the primary goal requires actually 
building a system. Therefore, a prototype 
(MOORE) was developed, which demonstrated 
the concept of a diagnostic system. TDRS 
PACES is currently under development with 
the goal of being a system which can be 
implemented. Therefore, it must contain 
sufficient information to do useful work, and 
present that information in a usable format. 

Objectives 

To meet these design goals, TDRS PACES has 
the following objectives: 

• Capture diagnostic knowledge of Power 
and ACS subsystems, sufficient to allow 
identification of the most likely component 
failure at a level which would allow 
switching to redundant circuitry. 

• Maintain information on failed 
components and anomalies of each 
spacecraft so that advice can be tailored to 
the unique characteristics of each 
satellite. 

• Capture block function diagrams, 
schematics, and illustrations of physical 
spacecraft components for use by 
spacecraft engineers. 

• Integrate diagrams with each other so 
engineers can move between the types of 
representation and levels of detail. 

• Integrate the diagrams with TDRS 
PACES in such a way that the diagnostic 
function provides initial access to the most 
appropriate diagram for any identified 
fault. 


• Provide NASA Code 405 personnel with 
sufficient experience in building expert 
systems so they can specify their 
requirements in requests for proposals, 
evaluate proposals, and judge the quality 
of expert systems built by contractors. 

• Build a system of sufficient complexity 
and ease-of-use to demonstrate the 
effective integration of expert system 
technology in daily orbital operations and 
test activities. (NASA 88) 

Hardware and Software 

TDRS PACES is being built using two Apple 
Macintosh IIs with nineteen-inch color 
monitors. Each machine has eight megabytes 
of RAM and a 100 megabyte hard disk. The 
Macintosh was chosen because of its graphics 
interface, ease-of-use, and consistent 
operation across applications. It was also 
seen as an economical alternative to much 
costlier workstations. Two machines were 
used to allow parallel development of portions 
of the expert system. The large amount of 
RAM and disk storage were chosen to insure 
the availability of adequate memory. 

The expert system was built using Neuron 
Data's NEXPERT OBJECT. NEXPERT runs 
on multiple platforms, all of which are 
general-purpose computers. It includes both 
rules and an object system - allowing for 
flexibility in design, and built-in access to 
external databases. A parallel product from 
Neuron Data, AlVision, is being used to 
create a graphical user interface. 

A New Image Technology flat bed scanner 
with associated software, is being used to 
input some of the graphics to TDRS PACES. 
Other images are created using several 
graphic packages, most notably Cricket Draw, 
Aldus FreeHand, and Adobe Illustrator. 

Laser writer output of graphics and screen 
dumps are used with our attitude control 
expert to eliminate shipping the computer 
equipment for some of the knowledge 
acquisition sessions. Shipment of computer 
resources is necessary because of the remote 
location of one of our experts. 
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Situation 

Creating an expert system to aid in diagnosing 
spacecraft anomalies is a difficult task. On 
the one hand, only a limited number of actions 
are possible. On the other, it is desirable to 
know which specific component failed and 
why. Such knowledge allows corrective 
action to be taken on future spacecraft, and 
assessment of risks associated with future 
performance. A conservative approach must 
be used when taking action to correct faults as 
irreparable damage could result if the wrong 
measure is attempted. 

TDRS PACES will operate in the diagnostic 
process as a consultant. The expert system 
will not make any decisions for the spacecraft 
engineers. Rather, it will function as a source 
of information and advice. TDRS PACES is 
designed to be used by ground support 
spacecraft engineers, and by spacecraft 
engineers during integration and testing of 
the spacecraft. 

Loss of Expertise 

There are several characteristics of TDRS 
diagnostics which suggest the use of expert 
systems technology. The spacecraft are being 
built over a prolonged period of time, and they 
will be used for many years. This means that 
there will continue to be losses of expertise due 
to personnel changes. New personnel will 
need to acquaint themselves with the TDRS 
satellites. 

Each TDRS is designed to have a shelf life of 
seven years, and a total active life, including 
storage of eleven years. Since flight 7 is being 
built now, it is possible that one or more of the 
satellites will still be used in the year 2000. 

At the same time, several key TDRS engineers 
are nearing retirement. Their expertise will 
be unavailable in later stages of TDRS 
operations. Many remaining personnel 
transfer to other programs as the major work 
of building the satellites ceases. Without 
means of capturing engineering expertise 
specific to the TDRS system, diagnosing faults 
and suggesting remedies for spacecraft 


incidents will become increasingly difficult as 
time passes. 

The satellites are being built in an overlapping 
fashion. At the time Flight 4 was being 
packaged for shipment to Cape Canaveral, the 
bus and payload had been mated for Flight 5, 
while Flight 6 was still in early I&T because 
many of its modules were used as 
replacements on Flights 3 to 5. 

Only three spacecraft will be on-orbit at any 
one time: two operational, one as a spare. 
Other spacecraft will be stored after assembly. 
In the future, they will be brought out of 
storage as needed. Currently under 
construction is Flight 7, a replacement for 
Flight 2, which was lost with Challenger. 
Much of the expertise which was available 
during initial I&T is likely to be unavailable 
for I&T of Flight 7, or when a satellite is 
brought out of storage and tested after several 
years. 

Once again, capturing the expertise which is 
available now will make it easier to deal with 
gremlins which crept in to a spacecraft while 
it was being stored. This same expertise will 
help with the I&T of Flight 7, a task on which 
there are several engineers unfamiliar with 
TDRS. 

On-orbit Problems 

Making repairs to on-orbit spacecraft is a 
rather limited process. All test data must be 
collected from telemetry points which were 
determined during system design. The only 
repairs which can be affected involve the use 
of redundant components. Again, all 
redundancies were part of initial system 
design. 

Because of the limited capacity for on-orbit 
repairs, satellites are built to be extremely 
reliable. Thus, relatively few on-orbit 
problems have been experienced. More 
difficulties were experienced in the 
integration and testing phase of the satellites. 
This I&T data provides some basis for case 
histories, but the number of faults in I&T is 
still limited. 


163 


Having few problems to comprise an historical 
record results in limited data from actual 
cases from which to gather diagnostic 
expertise. Thus, one must go to the models on 
which the spacecraft were built to diagnose 
new faults. 

Beyond the Prototype 

In 1987-88, a prototype expert system was 
constructed (Howlin, Weissert, & Krantz 88) to 
demonstrate the concept of applying expert 
system technology to diagnosing on-orbit 
problems in TDRS. The expert system was 
called MOORE after Mr. Bob Moore, TRW, 
Redondo Beach, CA, whose expertise was 
captured in the system. Mr. Moore continues 
to serve as an expert for TDRS PACES. 

The scope of TDRS PACES is wider than 
MOORE, and it has different objectives. While 
MOORE was a demonstration prototype, TDRS 
PACES is designed to be expandable into an 
implemented system. Different tools are being 
used, as well as a different approach. 

Different Objectives 

MOORE was designed from the start to be a 
demonstration prototype. It illustrated that 
Artificial Intelligence concepts could be 
applied to the diagnosis of on-orbit incidents 
for TDRS. It generated interest in AI 
technology, and enabled funding of a 
development system. 

TDRS PACES is designed to be a deployed 
system. Therefore, it must contain sufficient 
expertise for it to be useful to spacecraft 
engineers in diagnosing actual on-orbit 
problems. 

Case-based vs Model-based 

MOORE was based on reports of on-orbit 
problems with TDRS Flight 1. Thus, MOORE 
was at heart a case-based system. In addition 
to handling exact cases which actually 
occurred, MOORE was extended slightly to 
cover problems which were substantially the 
same as those actually experienced. 


There are two major limitations to the case- 
based approach. First, the number of on-orbit 
problems is extremely small. Only about 70 
anomaly reports were logged over a five year 
period. These reports covered all aspects of 
spacecraft operation. Only a small percentage 
of these were related to ACS difficulties, the 
only area addressed by MOORE. 

The second limitation involves making up 
problems or playing “what-if...” games. 
Hypothetical problems could serve as a basis 
for some expert systems, but not with TDRS. 
The satellite has many assemblies with 
thousands of piece-parts each. Hypothesizing 
could go on for many years, not be inclusive, 
and produce a system that would be too 
unwieldy to be implemented. The case 
approach also yields diagnoses which are 
much more specific than can be corrected in 
orbiting spacecraft. 

We have chosen a model-based approach for 
the current expert system. TDRS PACES is 
based on models of how the power and attitude 
control subsystems operate, rather than on 
actual cases. TDRS PACES will provide 
diagnoses only to the level of replaceable 
components or redundancies. Then, it will 
provide a spacecraft engineer access to 
schematics, function diagrams, and textual 
information which can aid the engineer in 
making a more detailed diagnosis of the 
problem. 

Expanded Scope 

MOORE was concerned with diagnosing on- 
orbit Attitude Control Subsystem problems. 
TDRS PACES expands that scope in several 
ways. While TDRS PACES will not have the 
depth of MOORE, it will have considerably 
more breadth. 

TDRS PACES contains information about the 
Power Subsystem. Mr. Al Gillis, NASA Code 
405, GSFC, will serve as the expert for the 
Power Subsystem. Power would have been a 
particularly difficult area for using a case- 
based approach as there have been no power 
anomalies with Flight 1. 
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MOORE was designed to serve as a diagnostic 
system only. In addition to diagnostics, TDRS 
PACES has an integrated exploration or 
teaching component. Since many of the 
spacecraft engineers who could be diagnosing 
problems with a satellite may have little 
knowledge of the specific spacecraft, a 
knowledge intensive component was 
considered to be essential to an implemented 
system. 

Flight 7 is still to be built and tested, and 
Flights 5 and 6 must be retested when they are 
removed from storage. So, TDRS PACES will 
include information about integration and 
testing. Including expertise about I&T 
activities makes TDRS PACES more generally 
useful. 

Interfaces 

TDRS PACES uses the interface tools provided 
by NEXPERT and AlVision for most of the 
interaction with users. User prompts, 
graphic interaction, and database accesses 
are all provided. Where these tools prove 
inadequate, they are supplemented with 
routines written in C. The C routines are 
compiled into the module which makes the 
NEXPERT library calls. This integration of 
external routines is an integral feature of 
NEXPERT. 

TDRS PACES will interface with the 
Reliability Analysis Report database. This 
interface will allow the engineer to gain 
access to historical information on the 
functioning of the spacecraft. The 
information from the database will be 
requested by a set of pre-planned queries. The 
engineer will be presented with options, 
allowing the selection of pertinent information 
on a specific spacecraft, or for all spacecraft. 
The returned data will be reflected to the user 
through pop-up windows. At this point, the 
engineer will be able to review the data to 
determine whether a similarity exists between 
one of the previous anomalies and the current 
problem. 

The expert system is designed to be used by 
spacecraft engineers, not software specialists. 
Therefore, a help facility is being provided 


which will allow for clarification for questions 
asked by the system by providing additional 
explanatory information. In some cases, 
instructions for moving from one screen to 
another are provided. Selecting the “WHY” 
option from the menu in dialog boxes, or 
clicking on the “HELP” button in graphic 
displays presents the additional information. 

For the majority of interaction with the 
system, TDRS PACES makes use of the built- 
in functionality of NEXPERT OBJECT. 
NEXPERT includes a dialog window which 
prompts the user for answers. AlVision 
allows for the creation of screens which can 
display information, and have “hot” areas. 
These areas can lead to other screens, convey 
information back to the NEXPERT inference 
engine, or display the values of objects within 
NEXPERT. NEXPERT also provides options 
for allowing text and graphics windows to be 
opened, displaying static information. 

The AlVision screens are used to display 
graphics, diagrams, and text; providing 
hypermedia facilities. The dialog window is 
used to obtain answers to questions. As TDRS 
PACES grows, some of the dialogs will be 
replaced by AlVision screens. In other cases, 
the AlVision screens will contain variable 
information - information which may be 
different for each spacecraft. 

Diagnostics 

Performing diagnostics for the satellites is one 
of the two main functions of TDRS PACES. 

The diagnostic system will be built to include 
both on-orbit and I&T anomalies. All 
recommendations of the expert system are 
purely advisory. Spacecraft engineers retain 
full control over all corrective actions. 

Two different types of diagnostics are required 
by spacecraft engineers in the diagnosis of on- 
orbit problems. At the action level, a diagnosis 
is required which will fix the problem - i.e. 
put or keep the spacecraft on-line, passing 
messages back and forth between other 
spacecraft and the White Sands Ground 
Terminal. In addition, the engineers must 
determine the exact component which failed. 
Individual components are not replaceable. 
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Identifying the failed part is a “deep” problem 
compared to the “shallow” problem of finding 
the failed assembly or subassembly of which 
the failed component is a part. 

The shallow knowledge represents a much 
smaller body of knowledge than the deep 
knowledge. It is possible to identify and 
represent this shallow knowledge in a 
reasonable length of time. 

System Structure 

Mr. Moore, the attitude control expert begins 
the diagnostic process by asking a standard 
set of questions. This set of questions is used 
as the introduction to the diagnostic phase of 
TDRS PACES. The attitude control questions 
are supplemented with questions about the 
time of year to gain initial information about 
the Power Subsystem. Because the spacecraft 
is eclipsed by the earth for short periods of 
each day in the fall and spring, different 
operations related to charging and using the 
batteries are performed before and during 
these eclipse periods. 

The initial questions for on-orbit satellites, 
along with the selectable responses in 
brackets, include: 

• Which spacecraft is experiencing 
problems? [FI, F3, F4] 


• On what day did the error occur (DD-MM- 
YY)? 

• At what time did the error occur 
(HH:MM:SS)? 

• Is this a valid spacecraft event? [Yes, No] 

• Is the spacecraft in fail-safe mode? [Yes, 
No] 

• In what mode of operation was the 
spacecraft when the problem was 
experienced? [Earth, Inertial, Normal, 
Sun] 

• What function were you performing when 
the problem was first noticed? [Antenna 
Slew, Momentum Dump, Monitoring, ...] 

Figure 1 illustrates the three types of dialog 
window provided by NEXPERT. They allow 
entry of boolean values, selection from a list of 
choices, and entry of text or numeric data. 

The default screens are used in all cases 
where they are not superceded by a specific 
graphic screen. 

Diagnostic fault trees are constructed for each 
redundancy. The trees specify path(s) leading 
to the diagnosis of a problem with the 
(sub)assembly. When a (sub)assembly is 
found to be at fault, the recommended action 
includes switching to the redundant 
(sub)assembly. The fault trees are 
implemented as production rules. 



Figure 1. Default response screens. There are three default response screens provided by 
NEXPERT. The one on the left allows entry of numeric values from the keyboard. The middle 
one allows for response to “Yes I No” questions. For text strings, NEXPERT presents all 
possibilities in a scrollable list as in the box at right. In all cases, an option is provided for the 
user to indicate “Not Known” - a response which can be used to bring up other questions. 
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Assemblies and subassemblies are considered 
to be objects in TDRS PACES. Separate objects 
are maintained for each satellite to allow 
recording failed components in specific 
spacecraft. The level of modeling extends to 
where components have redundancies. The 
objects are grouped into classes. 

Data which form the objects are kept in 
external database files for easy updating. 
When TDRS PACES is run, objects are created 
from the latest data. 

Exploration 

Perhaps the most important feature of TDRS 
PACES will prove to be the exploration facility. 
While the exploration function contains no 
complex reasoning, it provides the type of 
information which a spacecraft engineer will 
need in order to understand the Power and 
Attitude Control Subsystems of TDRS. The 
exploration facility is designed to be relatively 
large and extensible. 

The exploration facility contains schematics, 
function diagrams, textual descriptions, and 
illustrations of spacecraft components. They 
are linked by “hot spots” - areas on the screen 
which when clicked on, bring up other 
screens. 

Two types of linkages are available. Within a 
type of screen, similar screens with greater or 
lesser detail can be accessed. A screen of one 
type also allows access to other types of 
screens — other presentations of the same 
material. 

Figure 2 contains sample screens, illustrating 
their linkages. A diagram of the attitude 
control sensors and actuators will connect to 
more detailed diagrams of the sensors and 
actuators. By clicking the “hot spot” on a 
reaction wheel assembly in the sensors and 
actuators diagram, a graphic of the reaction 
wheels is presented. Then, clicking on the 
Function button brings up a text description of 
the reaction wheels. From the graphic of 
sensors and actuators, one can gain direct 
access to the function block diagram or an 
overall text description of the ACS. 


The information contained in the Exploration 
facility comes from briefings and project 
documents. The briefings were given by Mr. 
Bob Moore and A1 Gillis over several years and 
represent information they deem to be 
important. This briefing material is 
supplemented by information obtained from 
Messrs. Moore and Gillis in knowledge 
acquisition sessions. The primary document 
used for obtaining graphics and explanatory 
information is The TDRSS Spacecraft Systems 
Manual (TRW 85). Graphics were entered 
through drawing programs or by using an 
image scanner. 

Conclusions 

Through the process of building TDRS 
PACES, Code 405 is gaining considerable 
experience with the practical aspects of 
developing, managing, and monitoring an 
expert system project. This experience will 
prove to be of considerable value as more 
projects contain requirements for including 
expert systems. 

In many respects, TDRS PACES reflects the 
experience of many real-world systems 
regarding actual artificial intelligence 
content. The most useful feature of the system 
is the knowledge-rich, hypermedia section. 
While this contains much information and 
expertise, that expertise is captured in the 
graphic interface, not in the inferencing 
process. However, it is important to 
remember that TDRS PACES is designed to do 
useful work — work which saves time and 
money - not to break new ground in 
theoretical areas. 
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Figure 2. Types of exploration screens and their linkages. From a graphic of the ACS sensors 
and actuators (a), clicking on the “Block” button brings us a block diagram of the ACS system (b). 
Clicking on the “Graphic” button on the block diagram, brings up the graphic of the system. 
Clicking on the reaction wheel section of the ACS Graphic (a), brings up a detailed graphic of the 
reaction wheels (c). Selecting the “Function” button brings up a textual description of the 
reaction wheels (d). 
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